Presently, computer users desire a computer system that supports a presentation of multimedia data, including graphic, audio, and imaging information. The popularity of multimedia presentations has encouraged the development of a variety of multimedia formats, such as compressed video (e.g., Moving Picture Experts Group (MPEG)), uncompressed video, compressed audio, and uncompressed audio. Earlier multimedia systems were compatible with a limited set of data formats and typically operated in a uniform manner to play a video and/or audio stream.
Later multimedia systems used replaceable sections within a rigid format to handle more than one type of multimedia data format. The replaceable sections represented functional components for processing multimedia streams. The functional components typically included a file reader, a data stream splitter to split video and audio data streams, a decoder for decoding each data stream, and a renderer for displaying the video stream and presenting the audio stream. The default file reader might be replaceable with a different one to support the reading of a different file format. Likewise, the decoder was replaceable to allow a different encoding technique, and the renderer was replaceable to vary the presentation of the video and audio streams.
Although the sections of these multimedia systems were replaceable, the processing of multimedia data has a fixed format and ordering. For example, a data stream splitter followed a file reader, a decoder was placed before the renderer, and so forth. It was difficult to disable or bypass one or more of the ordered functions of this structured system to perform complex multimedia tasks. For example, this rigid format prevented the simple combination of two files, each including a video stream, to produce a “merged” video effect.
To handle the wide variety of data formats and to perform complex processing tasks, a flexible multimedia system has been designed to automatically combine software components, called “filters,” into a graph comprising a chain or chains of filters. This system typically constructs a “filter graph” by connecting the output of one filter to the input of the next filter to create a data system to allow, for example, splitting and merging of data streams. By connecting filters together via a graph mechanism, it is possible to perform complex operations more easily than other structured multimedia architectures. The range of processing tasks that filters of a graph may perform is greater than tasks performed by a multimedia architecture having a rigid format.
Some existing multimedia environments allow for the automatic creation of a filter graph given an input type and a desired output type. There may be combinations of filter graphs that satisfy a given input/output type (e.g., two filters may have the same inputs and outputs). When creating a filter graph, these multimedia environments search through a list of filters that satisfy a given filter graph and picks a filter for loading to the filter graph. However, it is possible that the filter loaded to the filter graph has not been tested against a multimedia application during development. Furthermore, some multimedia environments also allow filters to have “merits,” which specify a priority order for which the filters are to be loaded. Thus, when these multimedia environments attempt to create a filter graph, they search for and load filters that have higher merits. One problem associated with such merit figures, however, is that poorly designed filters are often mistakenly given a higher merit.
Furthermore, some multimedia applications such as editing applications place more stress levels on filters since they process transitions between media clips that desire a simultaneous decoding of two clips and a mathematical combination of resulting frames. In particular, these multimedia applications may invoke filters developed by third parties during preview and publication of a video/audio timeline. These third-party filters may not have been tested against the multimedia applications. Moreover, some of these third-party filters, as well any filter which does not take into account concurrent instances, are designed for Digital Versatile Disc (DVD) playback applications that do not desire a simultaneous decoding of different clips and thus are not written to have multiple instances called concurrently. In addition, an automatic graph builder may add filters which should not be part of the graph, but because of the merit figure assigned to the graphs these filters are inserted into the graph. Accordingly, crashes in multimedia applications caused by third-party filters have become a leading cause of dissatisfaction among computer users.
Given the number of different third-party filters available, it is likely that on a given environment, there are some corrupt filters or filters that have not been tested for different multimedia applications. These filters may cause a multimedia application to crash. Often, these filters are not integral for a proper operation of the applications, and excluding them from a filter graph may improve the reliability and stability of the applications. However, it may still be desirable that multimedia environments allow third-party filters to be included in the creation of filter graphs so that the environments may process new coder/decoders (codecs) developed by third parties. Thus, it may not be feasible to disable filter graphs or to disallow third-party filters completely. Also, some application features may desire to plug third-party transitions and effects into a video/audio timeline.
Accordingly, a solution that effectively improves reliability and stability of a multimedia application is desired.